home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1997 April / EnigmA AMIGA RUN 17 (1997)(G.R. Edizioni)(IT)[!][issue 1997-04][EAR-CD].iso / EARCD / util / boot / lowfrag13.lha / LowFrag.readme < prev   
Text File  |  1996-12-20  |  9KB  |  227 lines
  1. LowFrag v1.3 (20-Dec-96)  -  By Eric Sauvageau.
  2. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  3.  
  4. 0. History
  5. ~~~~~~~~~~
  6.    1.0 - First version - limited release.
  7.  
  8.    1.2 - Wouldn't work if no threshold value was specified from the command
  9.          line.
  10.  
  11.        - Fixed major enforcer hits :(
  12.  
  13.    1.3 - The AllocMem() patch wasn't properly patched (Wrong LVO).  Patching
  14.          the right one slowed down the system too much, so I simply 
  15.          removed it.
  16.  
  17.        - Now promotes allocs larger than the treshold instead of the smaller
  18.          (more common) ones.  It's a bit faster.
  19.  
  20.  
  21.  
  22. 1. Introduction
  23. ~~~~~~~~~~~~~~~
  24. "Out of Memory" the program told you.  What the heck?!  You have 2 megs of
  25. memory, 1 of which is free, and this 300 Kb program tells you 
  26. "Out of Memory"?  Then you open a Shell, type "Avail" and press Return.
  27. And Avail tells you this:
  28.  
  29.  
  30. Type  Available    In-Use   Maximum   Largest
  31. chip    1004888   1091240   2096128    207000
  32. fast          0         0         0         0
  33. total   1004888   1091240   2096128    207000
  34.  
  35.  
  36. This is called "memory fragmentation".  You have a "playground" of
  37. 2 Megabytes of RAM, but little programs are playing all over it, leaving
  38. only small areas free between each of them rather than one large free area.
  39. Yes, programs are like kids, they love to scatter everywhere.
  40.  
  41.  
  42. Unfortunately, it's pratically impossible to "unfrag" memory on the Amiga.
  43. Best thing you can do is to try an "Avail Flush" in a Shell, hoping that it 
  44. will remove a library from memory, allowing two small areas of 200 Kb each 
  45. to join together into a 400 Kb large area, the library separating them
  46. being freed from memory.
  47.  
  48. Ok, so we can't unfrag memory.  How about giving a little more organization
  49. to these "kids", telling them to play together rather than scattering all
  50. over the playground?  Well, it ain't that simple.  Kids never listens.
  51. You know this, you've been there too.
  52.  
  53.  
  54. Fortunately, the memory "playground" has a little more order than a 
  55. playground invaded by kids.  Before getting access to the "playground", 
  56. you must ask Mr. Exec if you can go play on it, and where to play.  But 
  57. you see, Mr. Exec is very busy watching Mrs. Paula sunbathing on the other
  58. side of the park, so he's doing a quick'n'dirty job: he starts looking 
  59. from the closest area, spots the first area large enough for the one
  60. asking for space, and directs it there.  And Mr. Exec goes back to the 
  61. sight of Mrs. Paula, sunbathing in a tiny bikini.
  62.  
  63.  
  64.  
  65. 2. But I have an Amiga, no a kid playground!
  66. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  67. This is how Exec works.  When a program needs a memory area for its code 
  68. or data, it asks Exec to assign it a free area, and goes there.  This is 
  69. what the DOS does when you load a program: it asks Exec for areas where it
  70. can put the program.  And then, the programs asks Exec for areas where it
  71. can put the various data, libraries, etc...  But problem is, when the 
  72. program leaves, some of the data can stay in memory:
  73.  
  74. 1) Files created in the Ram Disk.
  75. 2) Libraries/devices loaded.
  76. 3) Files in the clipboard, usualy located in the Ram Disk.
  77. 4) Areas "forgotten" by the program.
  78. 5) Small "patches" left in memory.
  79.  
  80. And there is surely a few other cases.
  81.  
  82. Or, another situation:  Two programs are loaded one after the other.  The
  83. first one leaves, but not the second one.  Result: an area of the size of
  84. the first program is left, separated from the remaining free memory by the
  85. second program.
  86.  
  87.  
  88. We can't really fix this problem.  But we can help reducing the number of
  89. situations where it can occur.  This is what LowFrag can do.
  90.  
  91.  
  92. 3. Soooo... What does LowFrag do?
  93. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  94. LowFrag will eliminate one of the cases where memory gets fragmented:
  95. the case where a program is loaded (100-500 Kb) in memory, and exists
  96. leaving some data behind it in memory (clipboard, libraries, etc...).
  97. Or when another program puts small allocations just after the large
  98. program, so when the large program quites, it leaves a rather large 
  99. block separated from the main area.
  100.  
  101. How does LowFrag works?
  102.  
  103. Usually, the data left in memory are small blocks (small when compared
  104. to the programs, that is).  So, we could reduce fragmentation by
  105. separating the large allocations (usually applications) from the smaller
  106. allocations (usually data, patches, etc...).  Exec's memory allocation 
  107. has a flag which will do just that:
  108.  
  109.    MEMF_REVERSE   -> Allocate memory starting from the top of memory.
  110.  
  111. When this flag is used on a memory request, Exec will start looking from
  112. the TOP of memory for a free area, rather than from the bottom (as usual).
  113. So, we can separate allocations by putting the "MEMF_REVERSE" flag to the
  114. smaller allocations, so they stay out of the way of the larger allocations.
  115.  
  116. This is what LowFrag does.  When an allocation is larger than a threshold
  117. value, the allocation gets "stamped" with a "MEMF_REVERSE" flag, telling
  118. Exec to find it a suitable area by starting from the top of memory.  So 
  119. when the application leaves, any smaller allocations left in memory won't
  120. clutter the area usually needed by large.
  121.  
  122. Here's a concrete case that I tested myself where LowFrag reduce 
  123. fragmentation:
  124.  
  125.  
  126. 1) Launch a terminal (Terminus)  - Around 400 Kb
  127. 2) Cut some text into the clipboard - A few bytes
  128. 3) Exit the terminal.
  129.  
  130. Without LowFrag: The memory is splitted by the clipboard content.  But
  131. with LowFrag, the clipboard content is at the top of the memory.  So rather
  132. than "cutting" a 400 Kb block from the main area, it will probably cut 
  133. around 10-50 Kb (small allocations done by the terminal: serial.device, 
  134. various libraries, etc...).  We can call this an improvement I guess :)
  135.  
  136.  
  137. 4. Sounds like fun... I want to use it!
  138. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  139. Simple: copy LowFrag in your C: directory, and somewhere in your
  140. startup-sequence (usually just after SetPatch), add this single line:
  141.  
  142. Run <>NIL: c:LowFrag value
  143.  
  144. value is the threshold limit: allocations smaller than this value will get
  145. "promoted" with MEMF_REVERSE.  If you don't put any value, then the default
  146. threshold of 32768 (32 Kb) will be used.  I found this value to work very
  147. well on my own system, so try the patch first with this value, adjusting it
  148. afterward to suit your system.
  149.  
  150.  
  151. LowFrag can be aborted at any time by sending it a CTRL-C code, altough 
  152. this isn't recommended: if another program patches AllocMem() or AllocVec()
  153. afterward, it's most likely that the system will crash.
  154.  
  155.  
  156. 5. That's it
  157. ~~~~~~~~~~~~
  158. So enjoy.  The whole thing is released as public domain.  If you have any
  159. ideas on how to improve the thing, the source code is there in the 
  160. archive (written in Amiga E, with some inline assembly), so just go ahead.
  161. A few possible ideas:
  162.  
  163.  - Promote allocations which has the flag MEMF_PUBLIC.
  164.  - Have the user define a list of tasks which should always get promoted
  165.    (altough this could probably slow down the system.  Memory allocation
  166.    is one of the cornerstones of the OS, so any changes there will reflect
  167.    on the whole system's performances.
  168.  
  169.  
  170. 6. Hints & tips for programmers
  171. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  172. You can help reducing the memory fragmentation problem.
  173.  
  174. a) When possible, use the memory pool system available since Exec V39
  175.    (it's been in amiga.lib since V33 I think?).
  176.  
  177. b) For large executables, split it into separate hunks, so they could
  178.    be loaded even on a fragmented system.
  179.  
  180. c) Make sure you don't leave anything behind when you quit your program,
  181.    unless when needed.  Testing for memory leaks should be part of every
  182.    debugging routine (Enforcer won't intercept by itself ALL kind of bugs,
  183.    guys.)
  184.  
  185. d) When doing an allocation meant to STAY in memory, why don't use the
  186.    MEMF_REVERSE flag?
  187.  
  188. e) For large applications, it is often a good idea to put part of the code
  189.    into a shared library, and keep the library open only when it is needed.
  190.    This way, it can be flushed from memory when the system needs more
  191.    memory.
  192.  
  193.  
  194. 7. The Author
  195. ~~~~~~~~~~~~~
  196. I can be reached via Fidonet:  Eric Sauvageau>1:242/907.0
  197.  
  198. Or via Internet:
  199.  
  200.    merlin@thule.icenet.no
  201.    dream@step.polymtl.ca (this is a friend's account)
  202.  
  203.    http://thule.icenet.no/~merlin
  204.  
  205. This whole little thing is released on the Public Domain.  Do whatever you 
  206. want with it.  As for I, I decline any responsability if you encounter 
  207. problems while using this patch.  It's been in use on my system and 
  208. a friend's for many weeks before I released it, without any problem.
  209.  
  210.  
  211. I also wrote a few other goodies for the Amiga:
  212.  
  213. TDPrefs   - Preferences editor for the trackdisk.device.
  214. MFormat   - Replacement for CBM's "Format" command.
  215. DevsMan   - Manager for the Devs: and Storage directories.
  216. NewIcons3 - The ultimate icon enhancer.
  217. XPKatana  - GUI/ARexx interface for the XPK packing system.
  218.  
  219.  
  220.  
  221. See ya!
  222.  
  223.  
  224.    Merlin
  225.    ------
  226.  
  227.